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ABSTRACT 



The Department of Defense has been continually plagued 
with problems in software development in terms of cost, 
reliability and performance. To combat these problems, 
Congress enacted Public Law 101-511, requiring that after June 
1, 1991, all Department of Defense software be written in the 
programming language Ada. However, for this transition to be 
effective, training of personnel must be accomplished. This 
thesis addresses issues involved in training of personnel in 
the Department of the Navy in Ada, the philosophy of training, 
the number of personnel to be trained and the potential costs 
involved. 
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I. INTRODUCTION 



A. DOD PLAGUED WITH SKYROCKETING SOFTWARE COSTS 

The Department of Defense (DOD) has substituted the 
strategy of developing highly-capable electronic systems 
rather than increasing the nuiobers of weapons in order to 
maintain the global balance of power. Unfortunately, this 
investment in computer technology has not realized its full 
benefit due to problems in the development of computer 
software. The complexity of computer systems has continually 
increased and has left DOD with the following problems 
(Subcommittee on Investigations and Oversight, 1989) : 

- software bought or developed does not achieve 
capabilities contracted for; 

software is not delivered at the time specified; 
software cost is significantly greater than anticipated. 
Soaring costs of software is not a new problem facing DOD. 
As early as 1973, DOD began investigating their ability to 
combat this phenomenon. This led to the development of the 
programming language Ada and its adoption in 1980 as an 
approved DOD high order language (HOL) . DOD continued to move 
in a direction of making Ada not only an approved HOL, but the 
"standard" HOL. In 1987, DOD Directive (DODD) 3405.2 
(canceled February 23, 1991) was published mandating the use 
of Ada for software development in Mission Critical Computer 
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Resources (MCCR) . DODD 3405.2 required that both a contractor 
and the in-house development team must obtain a waiver when 
not using Ada. DODD 3405.1, published immediately thereafter, 
served to recommend Ada as the standard HOL for automated 
information systems (AIS) , the Navy's business systems. No 
waiver was required for not adhering to this recommendation. 

Although Ada was mandated in DODD 3405.2 for MCCR in 1987, 

waivers were routinely granted whenever the software 

developers claimed COBOL, Fortran or something else would be 

more cost-effective. (Anthes, 1991) With a price tag of $30 

billion spent on DOD software in FY90 (Kitfield, 1989) , 

Congress became more interested in DOD software development. 

Also, as the United States faces a severe shortfall of 

software professionals, it is anticipated that over the next 

several years, DOD's demand for new software will soon equal 

the entire amount it currently has in use. 

. . .DOD made perhaps its single most important move to combat 
software shortages when it established Ada as a common 
software language in 1980. (Kitfield, 1989) 

DOD's problem with software development was no longer its 
own. On November 5, 1990, Public Law 101-511 was enacted and 
requires that: 

Notwithstanding any other provision of law, after June 1, 
1991, where cost effective, all Department of Defense 
software shall be written in the programming language Ada, 
in the absence of special exemption by an official 
designated by the Secretary of Defense. 

With the enactment of the law. Congress removed any doubt 
on the full-scale commitment it expected of DOD in using Ada 



2 



for all major software development efforts. Congress had 
decided to combat DOD's problem of buying affordable, reliable 
software on time. 

B. FORMATION OF AIP TASK FORCE 

In September, 1990, the Assistant Secretary of the Navy 
for Research, Development and Acquisition (ASN(RDA)) tasked 
the Director, Department of the Navy for Information Resource 
Management (DIRDONIRM) with production and issuance of an Ada 
Implementation Plan (AIP) . The AIP was to address Navy and 
Marine Corps (DON) tactical and non-tactical systems (MCCR and 
AIS) . The purpose was to directly assist acquisition/program 
managers in meeting the challenges of including Ada into new 
systems development and upgrades. An AIP Task Force was 
formed, and held its first meeting on October 4, 1990. The 
task force's target completion date for development of the AIP 
was April 1991. Appendix A contains the Task Force members as 
of that first meeting. At this time Public Law 101-511 had 
not yet been enacted, but it was clear that AIS software 
development was to come under similar guidelines as MCCR 
software development. The author of this thesis became a 
working member of the AIP Task Force in March 1991. 

The Ada Implementation Plan which has recently been 
renamed as the Ada Implementation Guide, is currently in draft 
format, being staffed and is expected to be issued in October 
1991. For clarity purposes, the term AIP is used. While 
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awaiting further implementation guidance for the Public Law 
from DOD, an interim policy guidance was signed on June 24, 
1991 by the Assistant Secretary of the Navy for Research, 
Development and Acquisition (ASNRD&A) . The interim guidance 
strongly states that all Department of the Navy components and 
activities, including contractors, shall use the programming 
language Ada for all systems and computer software through all 
phases of the life cycle. Exceptions are few and can be found 
in the interim guidance (Appendix B) . 

An estimate of the cost for full transition to Ada in FY91 
is $250 million. (AIP Task Force Minutes, 1990) 

C. SCOPE AND METHODOLOGY 

The primary emphasis of this thesis is Ada training within 
the Department of the Navy. To conduct Ada training for the 
25 major claimants of DON will require more than $130 million 
throughout the next five years. This $130 million includes 
only Department of the Navy in-house training for software 
professionals. Contractor training is excluded and will 
require additional funds. (AIP Education & Training Plan, 
1991-draft) 

The research for this thesis involved a literature review 
of applicable journals, informal interviews and data 
collection of training requirements. Interviews were 
conducted over an eight-month period with software support 
personnel in both the AIS and MCCR communities. The 
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interviewees were in positions of management, programming and 
systems analysis and included personnel in the customer 
organizations, the users. Their experience level varied 
within these positions. The training requirement data were 
gathered from the Office of Civilian Personnel and Management 
(OPCM) , the Bureau of Naval Personnel (BUPERS) and 
Headquarters, U.S. Marine Corps. 

D. THESIS ORGANIZATION 

This thesis begins with a discussion of the history of the 

development of the programming language Ada (Chapter II) . DOD 

has been plagued with skyrocketing software costs and has 

turned to Ada to help curb these costs. Ada manages 

concurrent processing, prevents operations on incompatible 

data, provides modular structure among program components, 

promotes reusability and is intended for a relatively long 

operational life thereby lowering maintenance costs. The law 

mandating Ada has endorsed a new philosophy of a single, 

transportable, standard support environment of software 

engineering. Ada is intended to be a tool for this purpose, 

but is not a cure-all. A recent study suggests that 

...the use of Ada can be a major — possibly essential- 
contributor to improving the development and maintenance of 
software, but it will in no way ''solve” all of the problems 
that plague the DOD in applying computer-based technology. 
(Emery, McCaffrey, 1991) 

Chapter III is an analysis of training and education in 
the Department of the Navy and focuses on the following 
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questions: Is education of the benefits of Ada taking place? 
What is the status of acceptance of Ada in the Department of 
the Navy and civilian institutions? Has Ada been successfully 
implemented at the Naval Postgraduate School and the Naval 
Academy? 

Chapter IV discusses the group dynamics of the Task Force. 
It begins with the origin of the direction of the Task Force, 
the original format for the AIP and continues through the 
final meeting in June 1991. The resultant Training Plan not 
only became an integral part of the AIP, but also will be 
issued as a stand-alone document. 

Chapter V discusses the cost categories of training for 
each category of programmers/analysts, managers, engineers, 
support personnel and trainers. A recommended training matrix 
is provided. A breakdown of the number of prospective Ada 
trained personnel for Department of the Navy and the overall 
cost for this training is also provided. 

In conclusion. Chapter VI gives recommendations about the 
future of Ada within the Department of the Navy. The course 
of a single high order language has been plotted by Congress. 
However, the success of Ada, and more importantly, software 
development lies in the hands of the programmers, analysts, 
managers, and trainers. 
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II. EVOLUTION OF ADA 



A. BACKGROUND 

In the early 1970 's, DOD experienced a trend of software 
costs exceeding hardware costs for development of major 
defense systems. (Boehm, 1973) In 1973, software was 46% 

(more than $3 billion) of the estimated total DOD computer 
costs of $7.5 billion. Embedded computer systems comprised 
56% of these software costs due largely to their complexity 
and size. (Fisher, 1979) 

It was estimated that at least 450 general purpose 
languages existed for DOD systems. Depending on the source 
cited, the actual number varied from 500 to 1500 of high order 
languages, assembly languages and language variance were 
considered. No single point of control for each language 
existed. Therefore, each project office was virtually free to 
create its own language or use an incompatible dialect of an 
existing language. The result: diluted training efforts, 
virtually no technology transfer among projects and a general 
diffusion of resources. (Booch, 1986) 

Since the majority of software costs in DOD were 
associated with embedded computer systems, DOD directed its 
attention to embedded systems. A suitable high order language 
did not yet exist that met the requirements for embedded 
systems. Embedded applications normally contain thousands to 
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millions of lines of code and have a typical life span from 
10-15 years. They change continuously due to dynamically 
changing requirements and must be highly reliable. Embedded 
systems are also typically subject to physical constraints due 
to target hardware, time and space. 

B. DEVELOPMENT OF ADA 

In 1975, the joint service High Order Language Working 
Group (HOLWG) was established. The HOLWG was chartered to: 
identify requirements for DOD high order languages, evaluate 
existing languages against these requirements and recommend 
the adoption/ implementation of a minimal set of programming 
languages. The HOLWG solicited input from all military 
departments, federal agencies, industry, the academic 
community and experts from the European computing community. 
These responses led to a complete set of requirements, 
representing the desired characteristics for a DOD high order 
language. Thorough examination found that none of the 
existing languages fulfilled these requirements. (Whitaker, 
1978) 

In April 1977, a Request for Proposal (RFP) was issued 
internationally soliciting designs for the new common high 
order language, DOD-1. Four contractors were chosen to 
continue development over a six-month period. Then the field 
was narrowed down to two finalists. The four original 
proposals had been color-coded in order to keep ensure that 



8 



the reviewers were unaware of the proposal's source. After 
two public design review meetings, the winner was chosen in 
May 1979. The Green language became officially known as Ada, 
the DOD's common high order language. The name, Ada, was in 
honor of Augusta Ada Byron, Countess of Lovelace, and daughter 
of the poet Lord Byron and considered the world's first 
programmer. (Booch, 1986) 

The preliminary language reference manual was made public 
and was also sent to more than 2000 selected experts for their 
comments. In addition, a public test and evaluation 
conference was held. Ada had successfully incorporated the 
particular programming requirements of embedded systems; 

- parallel processing; 
real-time control; 
exception handling; 

- unique I/O control. 

In December 1980, approval was granted for establishing MIL- 
STD 1815 as the approved DOD standard for Ada. (The number 
1815 was chosen since it was the year Augusta Ada Lovelace was 
born . ) 

Ada was later standardized and approved by the American 
National Standards Institute (ANSI) and the International 
Standards Organization (ISO) . (Skansholm, 1988) The 
government continued its support of Ada by requiring that an 
Ada compiler must pass over 2000 tests that check for 
conformance with the ANSI standard. Thousands of computer 
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scientists took part in the development of Ada and it has 
proven to be a powerful and consistent vehicle for the 
efficient creation of software systems. 

C. ACCEPTANCE AND FUTURE OF ADA 

After almost 11 years, Ada usage is finally expanding 
significantly. The reaction to Ada has ranged from fierce 
resistance to simple noncompliance of directives. However, 
considering it took more than 15 years to become widely 
accepted for COBOL, another DOD sponsored language, 11 years 
is not unusual. Early criticisms of both languages included 
inadequate tools and compilers. Compilers, now conform to the 
ANSI standard, and development tools have improved, thus 
absorbing many of the complaints offered by Ada critics. 
(Anthes, 1991) Ada 9X is a new version of Ada due for release 
in 1993 and will include functions specifically for 
business/AIS such as: 

- accepting binary-coded decimal data format; 
handling large data base manipulation; 
supporting the 64-bit fixed-point arithmetic. 

Listed as a study topic for inclusion in Ada 9X is support for 
object-oriented programming (OOP) . The proposed support of 
OOP concepts would adopt the qualities of inheritance and 
polymorphism. Object-oriented programming is particularly 
useful for evolutionary programming and would further enhance 
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Ada's ability to interface with other resources and software/ 
code reusability. 

The impact of Ada can be seen by the monetary expense. 
According to Focused Ada Research Corporation, in 1989 users 
spent $144 million on Ada software products, bought or used 
$831 million in hardware for Ada development and paid an 
additional $1 billion in direct salaries to Ada programmers. 
They estimated the value of Ada-based systems development 
projects ran in the tens of billions of dollars. However, as 
difficult as it is to measure DOD use of Ada, commercial use 
of Ada is even more difficult because users tend to guard 
their success stories as closely as trade secrets. (Anthes, 
1991) 

Congress has mandated that Ada will be adopted as DOD's 
standard programming language by enacting Public Law 101-511. 
DOD led the development of Ada with the hope that a single 
language would allow development of reusable code thus freeing 
scarce programmer resources to concentrate their development 
efforts on the unique software requirements of each new 
system. The strong software engineering discipline that Ada 
supports increases the level of attention on front-end 
requirements. Software development with Ada encourages a 
complete systems analysis approach and therefore life cycle 
considerations are an important aspect of each decision making 
process. 
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Public Law 101-511 has put high visibility on the choice 
of programming languages used for system development. 
Commands vying for funds are aware that non-compliance of Ada 
directives is a sure way for their programs to get ••axed” from 
the budget. The Department of the Navy commands may request 
waivers through Commander, Navy Information Systems Management 
Center (NISMC) , but they most likely will not be approved. 
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III. EDUCATION AND TRAINING OF ADA WITHIN DON 



A. EDUCATION AND TRAINING OVERVIEW 

The Armed Services have been traditionally known for 
outstanding training in their warfare specialties. Very few 
individuals are recruited pre-trained as "machine-gunners," 
"ship-drivers," or "jet pilots." With the split-second timing 
required in combat, many specialties are taught to "react," 
not to debate questions of "Should I?” or "Shouldn't I?". 
However, not only has training of DOD software professionals 
been traditionally poor, but DOD primarily selects program 
managers from those military officers whose career paths have 
reached a stage at which they are ready for large scale 
project management. Technical expertise in the respective 
project area is usually a secondary consideration. 
Furthermore, the difficulty in finding civil service personnel 
who are properly trained and who are also talented program 
managers has created a "quiet crisis" within DOD. 
(Subcommittee on Investigations and Oversight, 1989) 

The Department of Defense should not bare the entire 
responsibility for this shortfall since nonavailability of 
trained personnel, cost overruns, reliability and performance 
problems with software systems plague private industry as 
well. With the prediction of future shortages of software 
professionals due to increase demands for new software 
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(Kitfield, 1989) , DOD may find it even more difficult to 
attract the "best and brightest" members within the field. 
This predicted deficit is due primarily to DOD's inability to 
offer starting salaries that are competitive with those 
offered in private industry. (Subcommittee on Investigations 
and Oversight, 1989) 

There is an important distinction between education and 
training. 

Education involves an understanding of abstract theory; 
training involves gaining the skills necessary to accomplish 
a task. Without adequate training, users will not have the 
knowledge to use the technology to its maximum benefit. 
(Mensching and Adams, 1991) 

However, the Department of the Navy has failed in educating 
its personnel in the advantages that can be gained by using 
Ada in conjunction with sound software engineering concepts 
and in training its personnel in the principles of software 
engineering. (Knight, 1990) Even within the AIP Task Force, 
representatives of both the AIS and MCCR communities had not 
previously been educated in the benefits of software 
engineering complemented with Ada. This general lack of 
education in the area of software engineering must be overcome 
before training can ever achieve its full benefit. Software 
professionals need to be made aware that properly applied 
software engineering principals coupled with the programming 
power Ada has to offer, can lead to increased programming 
productivity. Productivity can be significantly increased 
because of the relative ease in which Ada program components 
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can be integrated, a reduction in program maintenance and an 
ability to reuse previously tested and validated code. 

B. DON ACADEMIC INSTITUTIONS 

The Department of the Navy's primary academic institutions 
have been slow to take the initiative in this arena. 
Therefore, it is no wonder civilian academic institutions have 
not been quick to incorporate Ada into their curricula. The 
Naval Postgraduate School (NPS) has been teaching Ada as its 
primary programming language since March 1989. However, the 
predominant philosophy has been that teaching Ada is no 
different than teaching other programming languages. It would 
be more effective to accompany the instruction of ADA together 
with the basics of software engineering. Otherwise, teaching 
ADA just as another programming language would be insufficient 
to introduce the concept of software engineering to its 
officers who may, one day, be program managers. Ada is not an 
easy language to learn and requires more experience than other 
languages before personnel can become proficient. (IIT, 1989) 
Therefore, by not teaching Ada in its full context, not only 
does the Department of the Navy miss an opportunity, it may 
actually have negative repercussions by "souring" its future 
program managers with such a difficult language. 

Although NPS offers Ada as a primary programming language, 
it is required for only two of the approximately 40 curricula: 
Computer Science and Information Technology Management. Of 
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the remaining 32 curricula, approximately 70% are considered 
technically oriented. Approximately 800-900 students a year 
graduate from NPS having absolutely no required contact with 
Ada. From a quick check of potential billets available, 
approximately 20% of these personnel will be future program 
managers for the Department of the Navy. 

The Naval Academy is in the process of revising its 
curriculum on Ada. Ada was previously taught as a first 
language at the Naval Academy, but was dropped from the 
curriculum because it was "too difficult." A recent article 
published by two instructors at the Naval Academy may account 
for this decision. 

The fundamental problem is found in the power of Ada. When 
constrained to the narrow confines of a simple classroom 
example, it can often inhibit the learning process. The 
language is a powerful tool that, in the hands of an expert, 
produces well-designed, elegant solutions. The languages 's 
features, however, can overwhelm the average student 
struggling to produce a 50 line program. (Spegele, Park, 
1991) 

Ada is a robust language and adds a level of complexity 
which can often impair learning for the novice. However, what 
kind of a message is the Department of the Navy sending to 
private industry, to vendors and to its own commands when 
their own academic institutions cannot solve these issues? 

C. EDUCATION AS A LONG-TERM INVESTMENT 

Proper education is the key for achieving the long-term 
benefits which can be gained through the use of Ada. Most 
students in civilian academic institutions are not yet taught 
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Ada in a software engineering environment context. Rather, 

they are just taught the mechanics of coding. (Subcommittee 

on Investigations and Oversight, 1989) 

Education and training are the keys to making the 

transition to the "Ada mindset." 

The mindset involves learning and applying new software 
engineering principles, modern methods like OOD (Object 
oriented design) , and advanced packaging concepts and tools, 
as well as the programming language itself. (Reifer, 1991) 

The emphasis here is on changing the way business is currently 

being done by looking at the "whole picture" in a software 

engineering sense. Making this change will place additional 

requirements on the education and training process. However, 

these requirements are minimal and the net payoff will be well 

worth the investment made. 
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IV. AIP TASK FORCE GROUP DYNAMICS 



A. ESTABLISHMENT OF THE AIP TASK FORCE 

The AIP Task Force was chaired by a member of the 
DASN(IRM) staff, with a deputy chair from the Space and Naval 
Warfare Systems Command (SPAWAR) . SPAWAR became involved 
because they had been in the process of drafting an AIP for 
the MCCR community. This AIP had previously been required 
under SECNAVINST 5234.2 (canceled by DODD 5000.1). Since much 
of the outline for the SPAWAR AIP had been completed, it was 
used as the base document. This may have been the cause of 
later discussions within the Task Force that the AIP was 
heavily weighted towards the MCCR community. 

B. BUILDING THE AIP 

The first meeting of the Task Force was held on October 4, 
1990, at SPAWAR in Arlington, VA. Appendix C is the initial 
outline for the AIP which was presented at that meeting (a 
section on education and training was not included initially) . 
The Task Force began with 17 members from various command 
backgrounds, some of whom were sold on Ada and others who were 
skeptical. Many of the members had been previously assigned 
to specific groups by the chairperson; however, those in 
attendance who were not previously assigned a specific work 
group were assigned at the meeting. 
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Many of the members had been seeking guidance on Ada 
policy and were anxious to comply, but had been overridden by 
managers who did not understand the long-range benefits Ada 
could offer in the areas of software acquisition and 
development. All members realized, however, that Ada is here 
to stay and with that knowledge alone, their respective 
commands would benefit. 

The purpose for the AIP was to describe a strategy for 
successful use of Ada and software engineering in the 
Department of the Navy for both MCCR and AIS acquisitions. 
The style was pre-selected to have a handbook flavor for ease 
of use by the Program Manager at the Systems Command level. 

Work continued on the expansion of the AIP. By late 
October of 1990, the Task Force was aware that the House 
Appropriations Committee (HAC) had proposed a public law to be 
effective June 1, 1991, which would mandate the use of Ada for 
all MCCR and AIS software developments. DASN(IRM) had 
requested the Task Force assist in preparing three point 
papers: the first, addressing implementation of the law; the 
second, addressing the waiver or exception process; and the 
third, the impact upon the Department of the Navy by 
accelerating the current program to meet the June 1991 date. 

The Task Force would fully support the HAC bill, but in 
the point papers they advocated a phased approach to 
transition to Ada over the next ten years. Training was 
addressed as a major impact area. It was noted that due to 
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compliance with previous directives, the MCCR community was 
significantly ahead of the AIF community in transiting to Ada. 
However, both the AIS and MCCR communities were a long way 
from full implementation, partly due to budget and hiring 
constraints. No additional money had been programmed for this 
transition and a portion of the previously approved funding 
had been deducted from the budgets for IRM due to the 
Corporate Information Management (CIM) initiative. CIM was 
consolidating ADP/IRM functions under one roof for DOD and the 
amount which had been deducted was the anticipated savings 
that the consolidation was to reap for DOD. 

By February 1991, with the enactment of Public Law 101- 
511, the purpose of the AIP had changed. The AIP was now 
directed at providing guidance to project managers and their 
staffs on implementing Department of the Navy policies and 
standards for use of the Ada programming language. An updated 
outline is provided in Appendix D. 

The final formal meeting of the AIP Task Force took place 
June 11-13, 1991, with a membership count of 37. (See 
Appendix F.) The page count of the AIP had grown 
proportionately with the number of personnel added to the Task 
Force. Copies of the AIP had previously been sent to members 
of the Task Force for their comments and returned for 
reproduction prior to this meeting. Section groups were 
divided up into separate small groups for reviewing comments 
and generating mark-ups of the AIP. 



20 



Many meinbers of the Task Force were disappointed that the 
AIP had become more of a Guide for Implementing Ada, vice a 
plan. During discussions concerning the Air Force's Ada 
Implementation Plan of January 29, 1989, which simply stated 
policy, the suggestion was made to take out Section 2.0 on DON 
policy and issue it as a separate instruction which referenced 
the "Guide" for assistance. By June 1991, the new title of 
"Department of the Navy Ada Implementation Guide" was given to 
the entire document. After further review, the chairperson of 
the Task Force agreed that there should be a brief plan, 
similar to the Air Force AIP, stating the Department of the 
Navy policy. The Ada Implementation Guide would still provide 
assistance to the program manager, but the policy would be 
stated in the instruction. 

A draft instruction was prepared which was signed later in 
June by DASN(C4I/EW/Space) . This instruction became the 
Interim Department of the Navy Policy on Ada (see Appendix B) . 
DASN(C4I/EW/Space) believed this would be a more effective 
approach in meeting the June 1, 1991 deadline established by 
Public Law 101-511. The Ada Implementation Guide is expected 
to be issued in October 1991. 

C. INITIATION OF EDUCATION AND TRAINING PLAN 

Training was initially listed as a subheading buried deep 
under Ada Related Issues in an appendix. In December 1990, it 
was decided that a separate appendix was to be added on DON 
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training requirements. In February 1991, an outline of the 
Training Plan, shown in Appendix E, was presented. The 
strategy behind the outline was that an actual training plan 
was needed to address the Department of the Navy's 
infrastructure training vice a guide for developing that plan. 
A representative from the Naval Postgraduate School was added 
to the training section to research Ada training sources and 
the costs associated with that training. The Training Plan 
came under severe scrutiny because it was intended to be 
published not only as an appendix, but also as a stand-alone 
document. Discussion continually arose concerning the value 
of Ada over other programming languages. Was training a 
programmer in Ada any different than training a programmer in 
COBOL, Fortran or any other language? The purpose of the AIP 
was not to convince anyone to use Ada, that came from Public 
Law 101-511. Rather, it was to emphasize that good software 
and systems engineering practices are the keys to a successful 
program. DOD now has a standard programming language which 
supports software engineering and in order to reap the 
rewards, proper training is required in areas other than 
simple programming. 

D. PRESENTATION OF THE EDUCATION AND TRAINING PLAN 

The Training Plan had expanded, but the DASN(C4I/EW/Space) 
staff now wanted more detailed statistics for use in future 
Program Objective Memorandum (POM) cycles. This required a 
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breakdown of personnel within DON who needed Ada training by 
organization along with the overall cost of this training. 
The author began gathering data on the number of DON personnel 
potentially needing Ada training and worked with Naval 
Computer and Telecommunications Station, New Orleans 
representatives on developing a complete cost analysis for the 
Training Plan. 

By June, 1991 the general consensus was that the Training 
Plan now contained too many DON statistics which would only 
serve to confuse project managers. However, in order for the 
Training Plan to be effectively used as a stand-alone document 
as well as provide useful input for POM cycles, the 
DASN (C4I/EW/Space) chairperson insisted that they remain a 
part of the document. The number of DON civilians requiring 
Ada training was believed to be low in the MCCR community. 
Members noted that virtually every civil service specialty 
series working in the MCCR community would require some type 
of Ada training. Further research continued on identifying 
additional civil service specialty series training 
requirements, after which the statistics were recomputed. 
Chapter V provides the details of the process used in 
identifying these requirements and how estimated training 
costs were obtained. 
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V. COST ANALYSIS AND CATEGORIES OF TRAINING 



A. DESCRIPTION OF PROBLEM 

The Naval Computer and Telecommunications Command (NCTC) 
requested a study on the impact of implementing the Ada 
programming language at the eight Naval Regional Data 
Automation Centers (NARDACS) . NCTC is a central design agency 
which invests heavily each year in software development and 
was one of the 25 major claimants used in the study. (A 
complete list is shown in Figure 1.) Of the 1020 programmers 
on board the NARDACS, only 31 programmers had received Ada 
training as of the end of FY90. Of those 31 programmers, 22 
had received only a one-week course and had not yet received 
practical experience in Ada. This study included in-house 
contractors as well as DON software support personnel. 
(Knight, 1990) 

After conducting interviews with several other commands, 
the author found this not to be unusual on the AIS side of the 
Department of the Navy. The MCCR side was found to be 
somewhat better, probably because Ada had been mandated since 
1983. 

Even fewer personnel are experienced to date in software 
engineering using Ada. Without additional training in 
software engineering, the Department of the Navy will lose 
many of the benefits Ada has to offer. 
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Chief, Bureau of Medicine and Surgery 

Chief of Naval Education and Training 

Chief of Naval Operations 

Conunander-In-Chief , U.S. Atlantic Fleet 

Conunander-In-Chief , U.S. Naval Forces, Europe 

Commander-In-Chief, U.S. Pacific Fleet 

Commander Naval Reserve Forces 

Immediate Office of the Secretary 

U.S. Marine Corps 

Military Sealift Command 

Naval Air Systems Command 

Naval Computer and Telecommunications Command 

Naval Facilities Engineering Command 

Naval Intelligence Command 

Naval Military Personnel Command 

Naval Oceanography Command 

Naval Sea Systems Command 

Naval Security Group Command 

Naval Special Warfare Command 

Naval Supply Systems Command 

Navy Field Offices 

Navy Staff Offices 

Office Chief of Naval Research 

Space and Naval Warfare Systems Command 

Special Programs Office 

Figure 1. Major Claimants 



Ada simply provides many facilities and mechanisms which can 
be used to support portability. The design of the 
underlying software system provides the portability of the 
systems, not the language which it is implemented. (Engle, 
1991) 
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Successful implementation of Public Law 101-511 requires 
establishment of a Department of the Navy education and 
training program designed to generate sufficient numbers of 
personnel proficient in software engineering using Ada. 
However, to date, no research has addressed the issue of how 
many software support personnel there are within the 
Department of the Navy or what the cost of training those 
personnel would be. The following questions needed to be 
answered : 

- What personnel need to be trained in software engineering 
using Ada? 

How many personnel will require the training? 

- What will the cost of this training be over a five-year 
period? 

Note: A five-year period was selected for budgeting purposes 

with the DON Program Objective Memorandum (POM) cycle. 

B. METHODOLOGY 

Prior to this author's participation with the Task Force, 
prior research had broken DON software professionals into five 
categories: managers, engineers, programmers/analysts, 

project support personnel and trainers. The following 
descriptions of each of these categories were extracted from 
the Ada Implementation Plan (AIP, 1991, draft) . 

1 . Manager 

Top and middle managers are defined as those 
responsible for high-level planning and decision making in 
organizations. They need awareness and orientation training 
on the benefits, capabilities, and differences of software 
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engineering using Ada so that they can provide planning, 
direction, and support for Ada implementation. 

Project managers are defined as those responsible 
for software projects. Usually, these managers select 
people for specific assignments, choose equipment and 
software tools, estimate costs, and plan schedules. 
Therefore, they need orientation and project management 
training on software engineering using Ada so that they can 
make informed technical decisions, develop plans, and 
conduct evaluations. Failure to understand the unique 
aspects of Ada will cause mismanagement and excessive cost 
in systems development and post deployment support. 

2 . Engineers 

Defined as those responsible for system engineering 
and top-level design, engineers usually interface with 
project managers and programmers and are responsible for all 
or major components of systems. They need orientation, 
software engineering, programming, development environment, 
and quality assurance training in software engineering using 
Ada. Many engineers may need only fundamental, not 
advanced, training in Ada programming; the need is dependent 
on the individual project and the interaction between the 
engineers and programmers. 

3 . Programmers and/or Analysts 

Programmers and/or analysts, defined as those who 
program and test computer programs, initially need 
orientation, software engineering, and programming training 
in software engineering using Ada. Later, they need 
training in Ada development environments and project 
management. Programmers and/or analysts with backgrounds in 
Pascal and other High Order Languages (HOL) incorporating 
systems engineering principles should adapt to and progress 
faster in Ada training than programmers and/or analysts with 
a strong background in languages such as COBOL and FORTRAN. 

4. Project Support Personnel 

Project support personnel are technical and 
nontechnical personnel who provide administrative support in 
contracts, purchasing, and budgeting or who deal with 
configuration management, quality assurance, technical 
documentation, libraries or data management control, 
partitioning, and integration. Project support personnel 
usually interact with project managers and systems 
engineers. They need training in the fundamentals of 
software engineering using Ada, particularly in the way it 
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differs from other HOLs (e.g., coding style, library 
structure) . 

5. Trainers 

Educators provide training support by establishing 
training plans, course evaluation, procurement, arrangement, 
preparation, instruction, and maintenance of training 
records. Training personnel usually have experience as 
administrators or instructors and interact with project 
managers. Trainers performing planning and administrative 
functions need an orientation to and understanding of the 
fundamentals of software engineering using Ada. Trainers 
preparing and performing Ada technical instruction need full 
exposure to and experience with Ada. 

The Education and Training group conducted interviews with 
various organizations on both the MCCR and AIS side and drew 
from their own experiences at NARDAC San Francisco and NCTS 
New Orleans. The author continued with those interviews, 
conducted further literature review and gathered additional 
numeric data. The numbers of software support personnel were 
gathered from the following data bases: OPCM, BUPERS and 
Headquarters, USMC and was correct as of April 30, 1991. 



C. COST ANALYSIS 

In seeking the number of personnel requiring Ada training, 
the five categories first needed to be broken into civil 
service specialty series and military specialties. Through a 
series of interviews and cooperative effort with NCTS New 
Orleans, the author broke down the categories into the 
following series and specialties. 
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1. civilian Series 



0334: Computer Specialist; 

0854; Computer Engineer; 

1515; Operations Research Specialist; 
1550: Computer Scientist. 

2 . Military Personnel 



Navy: officers; 

Subspecialty code 


Description 


— 0095P/0095Q 


Computer Information Manager 


— 0091P/0091Q 


Computer Technology; 


— 0090P/0090Q 


Hold both of above. 



Navy; enlisted (specifically DPs) ; 



— NEC 


Description 


— 2741 


Programmer/Assembler ; 


— 2742 


Programmer/ COBOL ; 


— 2743 


Programmer/ Fortran ; 


— 2751 

USMC; officers; 


Systems Analyst. 


— MOS 


Description 


— 4002 

USMC; enlisted; 


Data Systems. 


— MOS 


Description 


— 614 


Programmer/COBOL ; 


— 55 


Programmer/Ada* . 



can only be given as a secondary MOS (personnel must 
first hold MOS 614) 
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within the Department of the Navy these specialties totaled to 
14,091 software support personnel located in the AIS and MCCR 
communities. Software support personnel are broken down as 
follows: 

11,947 Civilians (Civil Service employees) ; 

- 268 U.S. Marine Corps Officers; 

- 614 U.S. Marine Corps Enlisted Personnel; 

- 455 U.S. Naval Officers; 

- 807 U.S. Naval Enlisted Personnel. 

Of these 14,091 personnel, not all would require Ada 
training since current Department of the Navy policy (Appendix 
B) does not require Ada for smaller software development 
(i.e., cost less than $50K in development and $5K/yr in 
maintenance) . After reviewing previous studies of past and 
projected software development, the group came to the general 
consensus to include 50% of all personnel and an additional 
10% to account for personnel turnover. Using these 
percentages a formula for establishing a baseline figure for 
Ada training was established. 

Baseline personnel to be trained = .5P + .lOT (1) 

where ; 

P = total software support personnel , 

T = .5P. 
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Each of the five categories of personnel was computed 
separately and totaled using Equation (1) . From these 
computations, it was determined that a baseline of 7750 
personnel needed to be trained over the next five-year period. 

NCTS New Orleans had been investigating all Ada training 
currently available and had estimated an average cost of 
$200/day for individual training. This average cost was the 
constant used in the cost analysis. Table 1 represents the 
overall training costs based on the recommended training 
matrix (Figure 2) . The initial conclusion was that a total of 
$57 million over the next five years would be needed to 
implement the proposed Department of the Navy training plan 
necessary to achieve full scale implementation of Ada. 



TABLE 1 

ADA TRAINING COSTS 





FY92 


FY93 


FY94 


FY95 


FY96 


TOTALS 






(dollars in 


millions) 




Manager 


.4284 


1.2750 


1.4926 


.6392 


.4284 


4.2636 


Engineer 


.3616 


1.0880 


1.2672 


.5440 


.3616 


3.6224 


Programmer 


4.8480 


14.5536 


16.9824 


7.2678 


4.8480 


48.5088 


Support 


.0512 


.1536 


.1824 


.0800 


.0512 


.5216 


Trainer 


.0510 


.1496 


.1734 


.0748 


.0510 


.4998 


TOTALS 


5.7402 


17.2330 


20.0980 


8.6148 


5.7402 


57.4162 
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AUDIENCE* 




ORIENTATION COURSES 


LENGTH 


MNGR 


ENGR 


PGMR 


SUPP 


TRNR 


Ada Overview 


2 Hours 


X 


X 


X 


X 


X 


Ada for Executives 


7 Hours 


X 








X 


Ada for Software Managers 


7 Hours 


X 








X 


Ada for Engmeers/Programmers 


7 Hours 




X 




X 


X 


Ada Acquisition Planning 


7 Hours 


X 


X 




X 


X 


SOFTWARE ENGINEERING COURSES 












Ada Software Engineering 


3 Days 


X 


X 




X 


X 


PROGRAMMING COURSES 














Ada MCCR Programming 


5-10 Days 






X 




X 


Ada AIS Programming 


5-10 Days 






X 




X 


Advanced Language Concept 


[need length] 




X 


X 






Ada as a First Language 


10-15 Days 






X 




X 


Ada Refresher Programming 


5 Days 






X 




X 


Ada Data Structures 


5 Days 






X 




X 


Ada Tasking 


5-10 Days 






X 




X 


Ada Project Experience 


Varies 


X 


X 


X 


X 


X 


DE\TLOPMENT EN’VTRONMENT COURSES 












Ada Program Support 














Environment 


2-3 Days 


X 


X 


X 


X 


X 


Ada Run-Time Environment 


2-3 Days 


X 


X 


X 


X 


X 


PROJECT MANAGEMENT COURSES 












Ada Project Management/ 














Ada Cost Estimating 


2-3 Days 


X 


X 


X 


X 


X 


Ada Contracting 


2-3 Days 


X 


X 


X 


X 


X 



• Legend 

MNGR * Manager 
ENGR “ Engineer 

PGMR - Programmer and/or Analyst 
SUPP = Support Personnel 
TRNR = Trainer 



Figure 2 . Recommended Training Matrix 
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However, as discussed in Chapter IV, when these data were 
presented to the Task Force in June 1991, personnel from the 
MCCR community found certain assumptions to be inaccurate. 
Specifically, they believed there were other civil service 
specialty series involved with Ada and that a much higher 
percentage of all software support personnel would require 
training. 

Through additional interviews, the Education and Training 
group discovered these personnel had a valid argument. 

Within the MCCR community, there was a much higher percentage 
of personnel that are and would be directly involved with Ada. 
The following additional civil service specialty series were 
added to the study: 



0855 


Electronic Engineer; 


1520 


Mathematician ; 


1300 


Physicist; 


0510 


Accountant . 



However, only those personnel with a civil service grade of 
GS-12 and above in these additional series were added. Most 
of these personnel fell in the category of managers with a 
much broader scope of responsibility than their series may 
indicate. Additionally, it was felt that more than 90% of all 
MCCR software support personnel would require some sort of 
training in Ada. However, the 10% turnover factor was still 
considered to be a valid assumption. 
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Therefore, for the MCCR community, the formula used for 
estimating the baseline number of personnel to be trained was 
revised as indicated in Equation 2. 

Baseline MCCR personnel = .9P + .lOT (2) 
where : 

P = total MCCR software support personnel, 

T = .9P. 

Upon further review, it was felt that Equation (1) was 
still valid for determine baseline training needs for AIS 
software support personnel. By including the additional civil 
service specialty series, the total number of DON software 
support personnel was estimated to be 26,929. This total 
included 11,850 additional personnel from the MCCR community 
and 988 from the AIS community. Recomputing using the revised 
MCCR formula, the total baseline figure for personnel was 
estimated to be 22,855. 

Table 2 is a breakdown of the training costs by categories 
over a five-year period and includes the total cost for 
training within each category. The total revised cost for 
training the baseline number of personnel in Ada, as shown in 
Table 2, is $130 million and was considered a reasonably 
accurate estimate by DASN (C4I/EW/Space) . 
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TABLE 2 



REVISED ADA TRAINING COSTS 





FY92 


FY93 


FY94 


FY95 


FY96 


TOTALS 






(dollars 


in millions) 




Manager 


1.7536 


5.2640 


6.1440 


2.6336 


1.7536 


17.5488 


Engineer 


2.1270 


6.3750 


7.4400 


3.1890 


2.1270 


21.2580 


Programmer 


7.4880 


22.4448 


26.1792 


11.2224 


7.4880 


74.8224 


Support 


.3900 


1.1730 


1.3680 


.5850 


.3900 


3.9060 


Trainer 


1.2852 


3.8556 


4.4928 


1.9224 


1.2852 


12.8412 


TOTALS 


13.0438 


39.1124 


45.6240 


19.5524 


13.0438 


130.3764 
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VI. RECOMMENDATIONS AND CONCLUSIONS 



A. RECOMMENDATIONS 

The current low acceptance rate of Ada within the 
Department of the Navy is due to the lack of a formal 
education and training program. This exists in spite of solid 
evidence that Ada has largely achieved its goal of providing 
a first-rate development environment for very large systems. 
(Emery, McCaffrey, 1991) 

A training matrix containing an average Ada curriculum for 
the five categories of software professionals was shown in 
Figure 2. It is a comprehensive list of courses, which are 
needed by most personnel, and was developed from training 
experiences and suggestions of the members of the AIP Task 
Force. However, project managers/training planners at each 
activity or for each project should conduct their own training 
needs analysis. The Project Manager (PM) first evaluates the 
current skill level of the work force on the project and then 
determines the skills required for the projected system 
environment. By comparing the two skill levels the Project 
Manager will have identified specific capability gaps. (U.S. 
General Services Administration, 1990) Finally, by using the 
matrix shown in Figure 2, the Project Manager should be able 
to realistically define the additional training required. 
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Training should be given precedence in the budgeting 
process. Federal funds should be provided for the development 
and dissemination of teaching methodologies which emphasize 
both software engineering and Ada. Encouraging civilian 
academic institutions will not only provide a broader base of 
software professionals for DON/DOD to choose from, but will 
also serve to reduce the projected shortages of software 
professionals. In addition, with more professionals trained 
in solid software engineering principals, code reusability 
will become more commonplace, thus also reducing the overall 
software demand. 

Code reusability, however, cannot be maximized without 
providing a greater flexibility in the software acquisition 
policies under which the Project Manager must operate. No 
royalties or compensation are offered to software developers 
for software reuse. Furthermore, DOD refuses to relax their 
policy on requiring complete data rights packages. The front 
end costs associated with building reusable code are high and 
many private industries are not willing to participate in low- 
bid contract competition knowing that their software will be 
included in a common DOD software library without future 
royalty considerations. (Kitfield, 1989) Top level 
acquisition managers must be educated in the long-term 
benefits of software engineering and a more flexible policy 
provided for Project Managers. 



37 



This short-term mentality must be overcome and long-term 

solutions put into effect. The cost of transition to Ada is 

no small matter in DON or in private industry. 

The traditional short-term financial orientation of U.S. 
firms works against the adoption of Ada and its attendant 
software engineering disciplines. Getting into Ada may cost 
hundreds of thousands of dollars in software and more in 
training, according to industry analysts. The savings in 
reusable code and reduced software maintenance may be huge, 
but might not show up for years. (Anthes, 1991) 

Kurt Lewin describes the process of bringing about 

effective change as a three-step process: unfreezing, 

changing, and refreezing (Lewin, 1947) . Chapter III discussed 

education and the Department of the Navy's failure to make 

this change obvious by educating its personnel not only in 

software engineering with Ada, but also with an appreciation 

of the problem. Mid-level managers must take on the burden of 

most of this "awareness-type" education. They must not assume 

that their personnel fully understand the problem or 

comprehend the full benefits which can be realized through 

full Ada implementation. Most often the personnel "in 

the trenches" are only concerned that their programs are valid 

and function according to specifications. 

Few of the development sites actually understand or employ 
software engineering principles. Therefore, touting Ada as 
supporting software engineering means nothing to the 
programmers in the trenches. And without convincing the 
"techies, any transition effort will be torpedoed. (Knight, 
1990) 

The House Appropriations Committee has acted as the change 
agent by enacting Public Law 101-511. However, with the 
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exception of the Interim Policy Guidance, very little has been 
done to assist in this change. The Corporate Information 
Management program under DOD has yet to issue any formal 
guidance on Ada. Department of the Navy commands must take a 
proactive approach to Ada. This will assist in the refreezing 
aspect of the change. There is strong opposition to Ada from 
many personnel, largely due to their inability to see the 
change in a positive light. Managers must look to the future. 
A loss of one or two personnel who refuse to accept the 
transition may cause an immediate drop in productivity, but 
may be a reality as managers see more existing and new 
development in Ada. 

B. CONCLUSIONS 

In order to ensure that the Department of the Navy will 
reap the reward of reliable, transportable, cost-effective 
software systems, we must train our personnel in project 
management and solid software engineering practices using Ada. 

Public Law 101-511 has set the course by mandating Ada. 
A standard has been set and should not be softened. Cost- 
effective, reliable software is achievable using software 
engineering with Ada and Department of the Navy should not be 
influenced by personnel who are unwilling to accept change. 
This is a long-term program and until metrics are available 
that can show that the premise of cost savings cannot be 
realized using Ada, strict adherence should be required. 
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Future research will be necessary and a cost-benefit analysis 

conducted as solid data becomes available. 

And the Lord said, Behold, the people is one, and they have 
all one language; and this they begin to do; and now nothing 
will be restrained from them, which they have imagined to 
do. 

Genesis 11:6 
King James Version 

The Department of Defense has adopted one standard language, 
Ada ANSI/MIL-STD-1815A-1983, which has been repeatedly 
criticized for its limitations. However, by taking full 
advantage of the inherent features of Ada and the future 
enhancements proposed for inclusion in the new version of Ada, 
Ada 9X, the Department of the Navy can make great strides in 
software development particularly in terms of cost, 
reliability and performance. 
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APPENDIX B 



INTERIM DON POLICY ON ADA 



This appendix is the interim Department of the Navy policy 
on Ada implementation. It was issued in June of 1991. 
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Bmti (A) U.S. CongrAAf. OtpATtAAnt of DAfonsA ApproprUtlono 
Act X991. Public Lav 101-511 (Nov. 5, 1990), 104 
StAt. 1856-1914 
(b) 0001 5000.2 Of 23 PAb 91 

fncl: (1) Inter Is Ade Progrtnalng Lenguage Policy 

Iteferenct (i) stAtSA *'not\rithAtAndino any othor provisioa of 
lav After June 1, 1991^ where cost Affective, all Departsent of 
Oefense software shall be vrittan in the progressing language 
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designated by the Secretary of Defensa". 

The office of the Secretary of befense has not yet provided 
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policy for the use of Ada both in Autosated Infersation Systes 
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Peftfence (b) resains applicable for MCCP end is only 
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Anticipating that isplenenting guldanoo from OSD soon vill bo 
availabla, thia policy vill resain in effect for aix sonths. 
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COKNAVPACZNOCOH 

COKNAVCOMTfLCOH 

CIHCLXNTPLT 

CXNCPACPLT 

CINCUSKAVEX7A 

COHSECONDPLT 

OOHTHHUyfLT 

COM815CTBPLT 

COMSrVENTHrLT 

ISPO 

pro (Air A8W) 
pro (TACA2R) 
pro (CM and UAV) 
pro <spAc«) 

DAPN (ATOXS) 

pro (SubaArint Syataai) 

PSD (SurfAca ASW) 



Bubji IHTERIK ADA PRDCRAMMINO LAWCUAGE POLICV 

Mt («) SSCHAVISST S200.32 
(b) 8ECNAV1KST 5231.1() 

(e) SECr^AVlHST 5430. 30C 

<d)' COSO 340S«1 Of 2 Apr 1587 
(A) DODD 3000.3 Of 23 F«b l»9i 

(f) MBS PIPS Publication 11-3 Of 9 Hay 19S3 

(g) DOS Standard 3167A of 39 Pab 89 

Attachaenta: (a) Ada txcoptlon Motiflcatlon Poroat 

(b) Ada uaivar Raquaat Format 

. 1. Purpoaa . To antablUh policy for using ths prograaming 
languags Ada In ths dsvslopmsnt and maintsnancs of aoftvar* for 
aystena managed under rsferanoss (a ) , (b) and (e) . 

2. BaOcoround . Public Uv 101-511, Section 8092, rtguirts that 
after June 1, 1991, where ooat effective, all Department of 
Defense software be written in the programming language Ada. This 
instruction provides Department of Kevy (DOM) policy conoerning 
the use of Ade and compliae with Departaant of Defenae (D0D| 
policy contained in refertncea (d) and (a). 

3. Definitiona . terms uaOd in thie Instruction era dafinad in 
referenea (f), except special terms defined as follows: 

a. Ada«Bftsed AST . An AST that spacifically eupports Ada 
software development (a.g., Ada eouree code generetor, OBMi with 
Ada intarface, ate.). 

b. Advanced Boftvare Technology fAStK Software teoli, 
life-cyola support anvironaants (including program support 
environments), non-procedural lenguagaa (4GLa), aodarn detabasa 
management systems (DBMSs), software tools, and other 
technologies that provide ij^reveaenta in productivity, 
useability, maintainability, portability, and ether banafita, 
over thoee capabilities commonly in uoa. 

0. Cpgnereial-eff-the*shelf fC0Ta> Software. Software 
(Including operating ayetems, utilities and stand-alone 
applications programs) already davalopad, tested, end sold to 
other Doo or commercial custoaars, aupported by a comaaroial 
vendor over the aystea life cycle, and requiring no govemaent 
modifications over the eystea life eyele. 

d. DQD-Acprpvad Wierh Order languages fHQLe|. The lenguages 
listed in reference (d): Ada, c/ATLAS, COBOl, <aiS-2, FORTRAN, 
JOVIAL, Kinimal BASIC, RASCAL, end SPI/1* 



•. gyeeptlQfl « An «xc*ptien ii approval tQ adopt an 
authorixad non-Ada approach containad In this Inatruetion which 
will xaquira only liAitad juatifioation and raporting. 

f. faurth_Ganaratlon f4GLal. Non-procadural 

coBptttar prooraaaing Xanguaoaa which eonaiat e< ooapaet^ Zngliah- 
liha atataaanta which daacriba tha ovarall taaka a ooaputar ia to 
carry out without apacifyino any individual atapa or thair ordar* 
for tha purpeaa of thia policyi 4dLa ineluda produota which 
ganaiat a BOL ooda* 

9 . wiioatana Daelaion Authorlrv. Tha individual daaignatad 
to approva antry of an acquiaition into tha nawt phaaa ih 
accerdanca with applicable diractivaa. 

h* hap Id Prototvpa . Quick trial iaplanantatien whoaa main 
purpoaa ia to aaaaaa tha faaaibility of tha product » verify 
ayataa raquiroBaivta and than diaoard. 

i. Validated gowpliar. A eoaptlar raqiatarad with tha 
Ada Joint Prograa Office (AJPO). A pro5 act-validated compiler/ a 
compiler that is register ad with tha AJPO at prolaet start or 
Milestone Q, is oonaidered validated for the entire life cycle of 
tha designated project* 

j* Waiver . A waiver ia approval to deviate from policy 
containad in this instruction which will raguira a datallad 
- justification to support* 

4. Applicability * This instruction appllaa to all avetaae and 
compotar eoftwara managed under rafaranoaa (a) through (o ) , all 
phaaae of the life oyclea of thoae ayatema and eoftwara / and all 
DOtf conponanta and aetivitias/ inoluding thair eentraotera* 

S* Asfifit* Thia instruction covers all computer eoftwara axeapt: 

a. Software which has alraady bean operationally fielded 
and for which mainta?«ance activity it raatrietad to error 
eoxreetion. 

b. /syetene that have entered production and deployment or 
have paeaed milaatona xt of rafarancaa (m) or (b), but hav^..net 
bean operationally fielded aa of 1 June 1991. 

e. Syetama for which a documented language oommitmant via 
made in compliance with previous policy* 

d. Kon-deliverahle software ae defined in reference (f) * 

e« Software devalued for dedicated proceesors that have 
16-bit or leas inetmetien sat arohitecturea and laea *^ haq 296K 
total memory. 
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r. Sofcwar* (or uaa in projacto at a alnola aita and coat 
laao than $50K in davalopmant and $SX/yr in saintananoa. 

Softvara %nrittan by Individual parional eoaputar/ 
vorXatation usart for paraonal or intra*offlca uaa, (or which DOK 
aaintananca activity support will not ba providad* 

a. policy * zt la PO)f policy tot 

a. Oaa tha Ada 'programing language ; as dafinad in 
AM51/NIL*STD*181SA<*1903, as tha singla, comon, high erdar 
oompattr programing language (or all eonputar rasourcaa* A 
validatad Ada coapilar and aodam ao(tvara anginaaring principles 
that (aoilitata tha use of Ada sust ba uaad» unlaaa a valvar or 
axcaption has boon approvod. 

b* Meet DON software reguirai»aAta« by reusing existing Ada 
coda vhanavar poasiblo. 

c* Grant waivers to tha policies in this instruction on a 
specific systas and subsystae basis only* Further, to base tha 
waiver decision on an analysis of total life-cycle costs, itapact, 
and potential for rauaa in othar DON and/or 000 aeguisitiohs. 

d. Identify needed technologies that have the potential to 
facilitate the uee of Ada in future systems acquisitions and te 
aggressively acquire thoae technologies* 

e* Whenever technically feasible and coat effective, 
acquire computere for which validated Ada compilara have been 
developed and to include language to this affect in oontractuel 
Betters pertaining to all syatam acquisitions* 

f. Use an Ada-based program design language that can ba 
suecasafully compiled by an Ada compiler, during tha design of 
software to improve tha portability of the softvara design* 

g* Use modem software anginaaring prinoiplea and Ada*baaed 
ASTs which facilitate tha use of Ada in order to roduco coats, 
shorten achedulaa, and improve software quality* 

7* txeeptio n cateq&riee . for the oatagoriea listed below, an 
exception request that documents a project's use of tha oitad 
approach is required* Exception requeeta will ba approved by the 
appropriate authority and retained for a minimum of 5 yeara for 
uet during milestone revieve/audits or pending waiver requests* 



«. COTS flo;tvar« and vandor updata iaplanantatiena My ba 
uaad vith an axamption raquait. Tha COTS say nalthar ba sediflad 
in function nor laaintainad by tha govanuiant* (Tha policy 
ragarding tha oaa of COTS aoftvara paeXagaa (a.g,^ DBNla, 
grapbioa) to ganarata application prograM that art not in Ada ia 
addraaaad in Advanead Softwara Tachnelogy.) 

b. Softwara which haa already baan operationally fielded 
nay be reuaad with an exception requaat aubjeet to tha folleving 
eondirionai (1) Tbm existing source code is wrlttea In a atandard 
' HOLi (2) The source coda aodifiad is lass than 1/3 of ooapllehle 
■ source coda. (Modified coda is the aus of code ehangea and 
additional codes. The 1/3 change will ba eaaaaaad againet tha 
anallaat unit of delivery (2167-CX, 7S35*SubayataB Specif ioetien) 
and (3) uat of asaanbly language ie identified end liaited to 
function! ragulred to allow tha standard HOL aoftvara to run on 
the targeted hardware. 

0 . Vaa of SQL (VzPS 127*1) with DSXSa for binding to Ada 
host arolicationa ia an Ada policy coapliant approach with an 
excaptien raguaat. 

d. Oaa of non-Ada for apeoial-purpoae application 
proeessora (signal proceseora, array proeaasors, 7FT procaaaore^ 
eto.) provided that Ada la used for the eennand prooeeaor or 
general-purpose processor that diracte the applieatlen ia allowad 
subject to an excaptien requaet. 

e« Non*Ada code nay ba used for a rapid prototyping projaet 
vith an exemption raguaat* Tha projaet nuat be converted to Ada 
prior to operational iaplaaentation. 

S> IfAlYirs* 

a. With the exceptions noted above ^ tSl or sore of the 
compilable aource coda davaloped muet ba in Ada or alaa a waiver 
ouat be obtained. 

b. Waivera are not required for developaeat of new Ada code 
or reuae/ 2 &odificatien of axiating Ada code. 

f. Proceduree 

a. exceptions 

(1) Milestone Decision Authority (NDA) ia tha approval 
authority for policy exeaptiona for progrtna under references (a) 
and (b). chiaf of Havy paaaaroh ie approval authority for policy 
exo^tions for prograna under refarenoe (e) . 
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(3) Exemption requtfitt thall be eubaltted to the KDA 
vie the appropriate chain of ooanand. The Ade Exception 
Notification Foraet ie provided in ettechnent (e). 

(3) syetem ecquieition end/or eoftvere deveXopnent vey 
proceed upon receipt of en endorseaent froa the KDA epproving the 
exception. 

b* tfeivere 

(1) CoaaendeTr Hevy Xnfcraetion Byeteae Kenegeaent 
Center (NI8KC) ie the epprovel authority for velvere to policy 
contained in this inetruetion. 

(3) Neiver requeete ehell be eubaitted to Coaaender 
KI6KC via the appropriate chain of coaaand. The Ada waiver 
req\Mtt foxaat ie provided ia ettachaent (b) . 

(3) tfeivere auet be approved by Coaaender » NXBNC 
before reltaee of the final paquaet for Proposal for contractor 
Boftware davalopaent and before syetea deeign begine for in-house 
devslopaent. 

10. RetponiibUiUti 

1. ABMfMAj ehell I 

(1) Esteblieh Ada policy for the DON. 

(3) Maintain overelght of the DON Ada Prograa to 
ineert Ada-ralated technology into DON eyeteas. 

b. Pmutv. aeelstant Bseratarv ef tAs New. CeMnend. 
Controls Cenaunlcatione end Coaputere. Intel lleenes/Elsetrpnie 
Werfare/Spiee. DABMrC4l/gW/SaegeK ehallt 

(1) Neview Acquleition Progreae for coaplienoe with 
thie policy. 

<2) Ensure that the policy end procedures in this 
inetruetion ere iapleaeated. 



c. Coffiiftander. Waw Tnipniiation flveteae Nanageaent Center 
iNISMCt ehallt 

(1) Ae DON Ada Waiver Approval Authority r aeke final 
diepoiltion on ell Ada waiver regueste. 

(3) As tbs DON Software Executive Offieiel in eu^>ort 
of ABXCEOA), serve ae the focal point for ell Ade progrea 
activities end aelntaln the DON Ada I^laaentation Plan. 
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d. ChUC-gl. gtaratlMf. fgwftii Chlaf. of Kaw aaatifeh 
. Aaaiatant for Adniirslatratlftft fay tha Undar Sagyt«fv ef 
^^a Naw.f *AOfiMt. eomnandant ef tha Mariha gerca fCHCj. aha III 

(1) Conduct on* tine rtviaw by 30 Saptosbar Ufa to 
•naura co&plitnca with this instruction within suberdinata 
organisations. Submit tha rasults of that raviav to eommandar# 
Havy Information Systaas Kanagaaant Cantar by 30 Oetebar If fa. 

(a) Snmura that all aetivitloa raapenaiblo for systams 
acgulaition and/or softvara davalopaant hava astabliahad Ada 
implamantation guidanca within fO days of issuanoa of this 
instruction. 

a. Hjlaatona Paelaion Authorltiaa ahallt 

(1) Malca final disposition on all Ada axeaption 

raguasta. 



(3) Attain Ada axeaption raguasts for a pariod of fiva 

yaars. 



f. Tha Chlaf ef MavalPaaaareh . during tha pariod of thia 
intaria policy ahall; 

(1) naka final disposition on Ada waivar raguasta 
subaittad from within his organisation. 

(2) at tha and of tha intaria polioy pariod# aaka a 
ona tlaa raport to DASH (C4X/tH/8) advising hia of tha naad to 
ravisa this policy to asst tha naads of tha laboratory ooaaunity. 



Adft IlcePTZOM MOtZfZCATXOll FosuaT 



covT LdttT . An exciptidn rtquoft autt Inelud* a oovar 
lettar (not to txcaad thraa paoaa) « aignad out by tha prepar 
raltasing authority in tha chain of ooaaand, to tha MiXaatona 
Daeifion Authority. Tha cevar lattar ahould ineluda at a 
ainiauar tha focal point (naaa, offica ayabol and phona), an 
idantification of apacific axaaptioa baii^ claimad^- tha dataila 
raquirad by Excaption Raquaat Content daaeribad on next paga^ a 
atata&ant Idantlfylng tha raaponaibla naintananea aotivity (in* 
houaa or contractor) aatoeiatad with tha loftwara involvM with 
tha axcaption raquaat, and a briaf auaaary of tha oontanta of tha 
packaga. Additional dataila say ba ineludad in attaohaanta to 
tha covar lattar. 






Attaohaant (a) 
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ZXCZPTZOS OOMDZTZOirf/ 

zzczmov ugoztT covtzvr ugoizzMivti 



^onditlga 1 . coTt and vandor updata 

iaplasantationa nay ba uaad with an axaaption raquaat* Tha 
axcaption raquaat will list tha eoDBaroial aoftvara balng uaad 
f or 'tha ayataa» Th^ p r o gra a offica will oartify that COTi ia 
naithar baing aodlfiad in function nor aaintainad by tha 
fovarnaant. 

coBdltioB > . Hauaa and upfrada of axiatlng DOO and 
govammant naintainad aoftvara that aaata tha following criteria: 

(1) Tha aourea coda ia writtaa in a KOL approvad in bOD 3408.1; 

(2) Tha aourea coda ftodifiad ia laaa than ona-third of tha 

co^liabla- aourea ooda (Tha one*thiTd uhanga will be aaaaaaad 
against tha auallaat unit of daliYary.)! and (3) Tha uaa of 
aaaeatbiy languaga ia idantifiad and lieitad to functions raquirad 
to allow tha standard UOL softwara to run on tha targeted 
hardware. An axcaption raquaat oust ineluda tha following 
information: Daacription of rauaad software, function, 

prograaoing languagaCs), aouroa lines of coda, anticipated 
Bodlflcations, and software sunpert activities aligned for. 
current and nodifiad software. Provide a daacription of Ada 
tranaitioA efforts and a statasant of saintananoa support. 

fonditioa 1 . An axcaption raquaat is naadad for non*Ada 
coda written for special purpose proeaasors (signal prooaaaera, 
array procaaaora, ate.,) provided that Ada ia uaad for tho 
cottmand grocaaaor or ganaral-purpoaa procaaaor that dlraeta tha 
application. Exception raquaata will identify tha eeanand and 
apseial purpose procasaora baing uaad, tha progranning languages 
baing uaad and their purpose, and tha nunbar of aourea lines of 
Ada coda and apecial purpoaa coda. 

Cenditioa 4 . Tha exception raquaat for use of 8QL (AH8Z, 
PIPS 127-1) with 8Qt coapliant OBKSa will identify tha eoBOBaroial 
DBMS being uaad and tha -aourea linaa of coda for SQL and Ada 
baing uaad for tho application. 

coaditioB -8 . Rapid prototyping for tha purpoaaa of 
aptclfvtng jjatarttinina or rafinlno ragulraiftanta . aa long ae/* tha 
project is inplamanted in Ada. Bvolutionary prototyping, for tha 
purpoaa of incroBantal ayatam davalopatant, nuat be dona in Ada. 

An axcaption raquaat xnuat daacriba tha rapid prototyping effort, 
non-Ada languaga uaad, and tha Ada tranaition plan. 



AttachBant (a) 
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Ada WAim RZQUXST FORMAT 

Covar Lattar: A valvar raquast packa^a auat includa a eovar 

Itttar <not to axcaad ona ptga) , algnad out by tha propar 
raXaaalng authority In tha chain of oomjMnd, to tha approval 
authority Cea&andar, HISNC. Covar Lattar aheuld include a focal 
point (offiea aynbol and phona) and a brief auaaary of the 
centante of tha package^ The detaili are to be included in the 
attachsante to the cover letter. The package suet include the 
aubparagraphe below and say not exceed ten pagan in length. 

Attachsant i^ Executive Sussaryt Thie attaehsant includea a 
daaoriptien of tha capabilitiea naadedr rationale and 
juatifioation for not uaing Ada (to include ooati aohedule 
parfomanea« rauee, portability and riak) , a deacription of the 
propoaad ay etas (hardvare, aoftvare, firsvare) and juotifieation 
and rationale for aalecting tha propoaad ayates. 

Attachsant 3, gyrtaa/Projeot Oeacrlptiona : This attachsant 

includaa dataila of the propoaad ayates, to include aeguiaition 
and contracting atatua (to the extant it ia pertinent to the 
waiver dacieion) , and deacription of both hoat and target 
hardware,, aeftvare and firsvare* 

Attachsant Life Cycle Coat Analyaiat Thia attachsant 
providea e coat end benefit analyeia which clearly above that the 
propoaad eolution ia sore coat effective end beneficial to DON 
over the project *e life than Ada. The anelyeie suit addreea both 
the Ada solution and the proposed eolution end include software 
developsent costs, life cycle seintenence costs, replacesent 
coats, training, portability, reuse, productivity, perforsanee, 
uaeability, docusentation, interfaeaa, echedulaa, and higher 
authority program diraotien* 

When computing the life eycla cost of an Ada eolution, any 
initial invaatsent in Ada support onvironsonta , tools, training, 
etc., Bust be asortorited over all future anticipated Ada 
project!. In aueh caaea the esortired asount of the total 
invaatsant ahould not oxceod fifty parcont, since the invaatsent 
would be used for future projects. 

Attachment 4, Transition Plant Ihie attachsant daaoribea 
your futura plana for moving to Ada if tha waivar is apprOVed. 
Addreaa all applicable factors, ineluding language features, 
cospilere, anvlronsente, bindings, training, education, 
achadulei, parsennal, costa and hardware. 



Attachsant (b) 
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AttACha«nt 9* Rltt)c Anal/sit: This att«cha«nt d«torib«a 

rifki «uch *• ftchtdulb, pmttomtncm, ••ourlty tnd Pthtr non- 
•eenomie i<suod onooeiotod vitb both tho Ado ond non-Ada 
tolutiono. 

Attaehaant 6, Statamant of Maintananoas Thif attaehaant 
(liaitad to ona pa^a) vuat idantify tba raaponaibla lalntananea 
activity (In-houaa or contractor) aaaoeiatad tilth tha aoftwara 
invelvad with tha axcaptien raquaat* 






Attaehaant (b) 



APPENDIX C 



OUTLINE FOR AIP AS OF SEPTEMBER 27. 1990 



Ada Implementation Plan 

Draft Outline with tentative personnel assignments 

[Editor's note: this plan has a strong handbook flavor. Some 

though needs to be given to identifying its intended audience 
and the message they are to receive.] 

EXECUTIVE SUMMARY 

1 . 0 INTRODUCTION 

[Clive Harding with everybody] 

1 . 1 Purpose 

1.2 Scope 

- Applicable systems 
Acquisition phases 

1 . 3 Assumptions 

1 . 4 Requirements 

1 . 5 Background 

1.6 DON Ada Management Organizations 

- DOD 

- SECNAV 

Navy and Marine Corps 



2 . 0 POLICY 

[Cdr Romeo with Capt Despasquale] 

- Ada advantages 

- Policy rationale 
Policy description 

- Waivers 
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3.0 PROGRAM MANAGER ADA IMPLEMENTATION GUIDANCE 

[George Robertson with Robert Calland, Dan Green, 
Marshall Potter, and Toni Stuart] 

3.1 Program Planning 

Cost and Schedule Estimation (development and 
life cycle) 

Resource requirements (development and life 
cycle) 

- Role of program office 
Role of Navy laboratories 
Training 

How and when to obtain assistance 

3.2 Acquisition Planning 

Technical requirements 

- Work requirements 

Proposal content requirements 

- Proposal evaluation criteria 

3 . 3 Systems Engineering 

Role of Ada (development and life cycle) 

- Risk management (planning, assessment, analysis, 
handling) 

Tradeoffs (money, time, capability, quality) 

- Technical performance measures 
Effect of Ada on: 

Reliability and Availability 
Commonality 

Hardware sizing and timing 
— Interfaces to existing systems 
— Prime/subcontractor relationships 
Scalability issues: 

— small-scale systems 

— medium-scale systems (>50K SLOC) 
large-scale systems (>500K SLOC) 

3.4 Software Engineering 

Role of Ada (development and life cycle) 

- Software development metrics 

Development techniques (prototyping, inspections, 
etc. ) 

Verification, Validation, and Acceptance 
Special concerns: 

— Ada PDL 

Ada design and coding practices 
CASE tools and Ada compilers 
multiple languages and computer types 
COTS (quality, legal, and life cycle) 
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- Categories of software: 

Operational (end-use) 

Simulat ion/St imulat ion 
Program generation and support 

3.5 Test and Evaluation 

Role of Ada (development and life cycle) 

(Ada's impact on schedule, quality, integration) 

3 . 6 Integrated Logistics Support 

- Role of Ada (development and life cycle) 

(Ada's impact on the ISEA and LCSA) 

4.0 ADA ENVIRONMENTS 

[Hank Stuebing with CDA, Frank Erwin, and Capt Thompson] 

4.1 Mission Critical Computer Resources 

- SECR ALS/N 

- COTS Ads 

4 . 2 Administrative Information Systems 

4 . 3 Program Support Environments 

- CASE 

- Tools 

5.0 CROSS-CUTTING ISSUES 

[Shirley Peele with Rich Bergman, CDA, and Cdr Romeo] 

5.1 Compilers 

Validation (ACVC) 

Evaluation (ACEC) 

- Selection 

- Vendor differences 

5.2 Ada Secondary Standards 

Role of Ada bindings 
Operating systems 

- Databases 
Graphics 

- Windowing Environments 
Software Development Tools 

(library management tools, source level symbolic 
debuggers, program viewers, Ada-oriented editors, 
static and dynamic analyzers, CASE, source 
reformatters, cross referencers, and recompila- 
tion analyzers) 
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5.3 



Ada transition 

Ada upgrade opportunities 
Reverse engineering 

5.4 Life cycle documentation 

- 2167A and HDBK-287 

- 2167A tools 

- 7935 

6 . 0 LESSONS LEARNED 

[Ron House with Rich Bergman and Capt Despasquale] 

6 . 1 AFATDS 

6.2 BSY-2 

6 . 3 ALS/N 

6.4 C2P Ada Shadow 

6 . 5 CAC Reports 

. . . about 3-4 others 

7 . 0 FUTURE DIRECTIONS 

[Tom Conrad with Cdr Romeo and Toni Stuart] 

7 . 1 Next Generation Computer Resources 

7 . 2 ALS/N 

7 . 3 Ada 9X 

7.4 DODD 5000.1 

7 . 5 Software Master Plan 

7 . 6 STARS 

7.7 MIL-STD-1838 (CAIS) 

APPENDIX A HELPFUL SOURCES (not in any order) 

[Cathy Ruiz with Joan McGarity and CDA] 

Ada Joint Project Office 

- Software Engineering Institute 

- DON-IRM 

- SPAWAR 
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Software Productivity Consortium 
Institute for Defense Analysis 

- PMS412 

Air Force Wright-Patterson ?? 

- Army CECOM ?? 

- AdaJUG 

Navy Ada Users Group 

Ada Information Clearing House 

APPENDIX B USEFUL REFERENCES 

[Software Master Plan Style] 

Policy 

- Standards 
Guidance 

APPENDIX C NAVY ADA PROJECTS [ALL NAVY TASK FORCE MEMBERS] 
[AJPO style] 

APPENDIX D MARINE CORPS ADA PROJECTS [ALL MARINE CORP TASK 
FORCE MEMBERS] 

[ADPO style] 

APPENDIX E GLOSSARY 

[Clive Harding] 

APPENDIX F USER UPDATE HOTLINE 

APPENDIX TBD ADA RELATED ISSUES (not in any order) 

[Robert Cal land] 

4.1 What to look for in your prime contractor 

4 . 2 What to look for in your subcontractors 

4.3 What to look for in your Navy laboratories 

4 . 4 Understanding the Ada development cycle 

Tailoring/modifying 2167A 
- Tailoring/modifying 2168 

4.5 Why training is so critical 
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4.6 What areas require special attention? 

- compiler vendors 
CASE tool vendors 

- Software Development Plan 



60 



APPENDIX D 



OUTLINE FOR AIP AS OF FEBRUARY 7. 1991 



Department of Navy Ada Implementation Plan 



This plan provides guidance to Program Managers and 
their staffs on implementing Department of Navy policies and 
standards for use of the Ada programming language. For the 
most part, guidance will be specific to Ada and assume some 
previous experience with software program management. 



Executive Summary 

1 . 0 Introduction 

2.0 Policy 

3 . 0 Program Manager Ada 
Implementation Guidance 

4 . 0 Ada Environments 

5.0 Ada Technology Issues 

6.0 Lessons Learned 

7 . 0 Future Directions 
A Helpful Sources 

B Useful References 
C Glossary 



1 page, short paragraphs, wide 
margins 



Formal 


4 


pages 


PM 






Formal 


4 


pages 


PM 


& 


staff 


Handbook 


15 


pages 


PM 


& 


staff 


Handbook 


10 


pages 


PM 


Engineers 


Handbook 


15 


pages 


PM 


Engineers 



Narrative 20 pages PM Staff 

Narrative 10 pages PM Staff 

(Organizations, Newsletters, 
Bulletin Boards) 

(patterned after DoD S/W 
Master Plan Part 2) 



D Navy Ada Projects 

E Marine Corps Ada Projects 

F Dept of Navy Training Plan 

G PPBS 
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APPENDIX E 



OUTLINE FOR DON ADA TRAINING PLAN AS OF FEBRUARY 7. 1991 

DON ADA TRAINING PLAN 



1 . INTRODUCTION 

- Discuss rationale for Ada training 

- Discuss importance of developing organic resources 

2 . REQUIREMENT 

Explain PL 8084 

- Meet software development functional requirements, 
schedules, and budgets 

- Reduce Post Deployment Software Support costs 

3 . TRAINING APPROACHES 

Formal (This section will address the course material 
and the target audience) 

— Top Management Overview (Executive Seminar) 

— Program Manager Introduction 
— Project Management/ Co St Estimating 
— Software Engineering 
— Object Oriented Program Design 
Fundamentals of Ada Programming 

Advanced Ada Programming Concepts and Techniques 
— Ada Development Support Environment (CASE Tools) 

- Informal 

Mentors 
— CBT/CAI 

Programming Teams (Projects) 

4 . TRAINING SOURCES 

- Academia 

- Consultants 
Service Schools (NEC) 

- Other DoD Courses 
In-house Training Programs 
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5. TRAINING PLAN DEVELOPMENT AND EVALUATION 

Length/Topics 
Environment/Equipment 
Hands-on Lab 
IS Projects 

Availability of Mentor/ Instructor 

Track Actual vs. Planned IS Functionality, Schedule, 
and Budget 

Document Feedback from Staff 

6 . LESSONS LEARNED 

MCCR Community 

MIS Community 

Scientific Community 

Private Sector 

Ada Joint Program Office 

Software Engineering Institute 

7 . FUNDING CONCERNS/ SOURCES 
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APPENDIX F 



TASK FORCE MEMBERS AS OF JUNE 20. 1991 



DEPARTMENT OF NAVY 
ADA IMPLEMENTATION GUIDE 
TASK FORCE PARTICIPANTS 



CHAIR: 

DASN(IRM) 


Ms. Antoinette Stuart 


DEPCHAIR: 

SPAWAR 


CDR Martin Romeo 


AJPO 


Mr. Currie Colket 


FCDSSA, San Diego 


Mr. George Robertson 


FCDSSA, Dam Neck 


Ms. Shirley Peele 
Mr. Guy Taylor 


FMSO 


Mr. Lester Hummel 


NADC 


Mr. Hank Stuebing 
Mr . Chuck Koch 


NADEP 


Mr. John McLaurin 


NAVAIR 


Mr. Tom Coyle 


NAVCOMTSSA 


Mr. Jim Welch 


NAVSEA 


Mr. Greg Engledove 


NCTC 


Ms. Joan McGarity 


NOSC 


Mr. Robert Calland 
Ms. Cathy Ruiz 
Mr. Rich Bergman 
Ms. Donna K. Fisher 


NSWC 


Mr. Dan Green 
Mr. Frank Ervin 
Mr . Eugene Hodgson 
Mr. Charles Flemming 
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NUSC 



Mr. Ron House 
Mr. Tom Conrad 



USMC 


Capt Gerald DePasquale 
Capt Dave Thompson 


USNA 


Mr. Doug Afdahl 
Mr. Jim Moss 
Major J. Spegele 


NARDAC, San Francisco 


Ms. Patricia Grandy 


NAVCOMTELSTA 


Mr. Bond Wetherbe 
Mr. George Frilot 


Navy Postgraduate 
School 


LCDR Jean Shkapsky 


NATC 


Ms . Kathy Steele 
Mr. John Shields 


SUPERS 


LCDR Anne Sullivan 


Booz, Allen & 
Hamilton 


Ms. Susan Scott 
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